The view system was refactored after it was analyzed on this page:OTrunk Old View System Analysis

It still has some problems

Problems

• OTJComponentService was created to provide a standard way for views to create new OTJComponentViews. However this service is not being used by the main view creator OTViewContainerPanel. This is because it is doing some fancy stuff to automatically handle xhtml views. That code which wraps the xhtml view in a jcomponent should be moved into the OTJComponentService.
• The way the OTDocumentView decides which view of an object to use is contorted. It uses a combination of the existance of a viewEntry, and the existence of a OTXHTML view to decide which to use. And it also factors in whether the view has a view mode or not.

Classes

View System Class Summary

Logic for deciding which view to use

Starting with the OTDocumentView here is the current logic.

Initial text parsing

1. if the viewEntry is not null (view-id attribute on object element), call:

   view = getViewFactory().getView(referencedObject, viewEntry, viewMode);
   

2. if the viewEntry is null request a view implementing the OTXHTMLView interface:

   view = getViewFactory().getView(referencedObject, OTXHTMLView.class, viewMode);
   

   1. if that returns null and the viewMode is not null then request a view implementing the JComponentView interface:

      view = getViewFactory().getView(referencedObject, OTJComponentView.class, viewMode);
      

3. if the resulting view is an instance of the OTXHTMLView then get its text and insert it in the document
4. otherwise leave the object tag in for the next stage

Component loading by HTMLEditorKit

If there are object elements in the text then the editor kit has been modified to ask the OTDocumentObjectView object for the Component to display. This view uses a OTViewContainerPanel interface to do this. It sets the object, entry, and mode of the viewcontainerpanel. The view container panel implements the logic of which view to use with the createJComponent method:

1. if the viewEntry is not null call getView on the view factory with the object, viewEntry, and mode
2. otherwise call getView on the view factory asking for a JComponentView implementation with the mode.
   • This causes problems because the mode of a JComponentView implementation might result in a XHTMLView. This should actually have been handled in the initial text parsing stage.
3. if the resulting view is OTJComponentView then that is saved as the currentView
4. otherwise a OTXHTMLView implementation is requested and wrapped with a OTXHTMLViewWrapper which is basically a OTDocumentView.
5. the getComponent method on currentView is used to get a component for the current view

test_sk (text/xml)